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[57] ABSTRACT 

A disk control system offloads to the disk controller 



much of the overhead associated with disk operations 
and makes the CPU available for other work. A com- 
mand block that fully specifies a user request for a disk 
operation is forwarded to the disk memory unit. The 
command block contains a unique identifier for tracking 
of user requests. User requests are executed by the disk 
memory unit in an order that is most efficient for the 
disk drive system. The status of a user request is com- 
municated to the CPU via an interrupt and a status 
block containing the unique identifier. The status block 
indicates status conditions such as command read, com- 
pletion and DMA channel request. The disk driver 
contains a work queue for user requests that have not 
been forwarded to the disk memory unit and a pending 
queue for user requests that are awaiting completion by 
the disk memory unit By manipulation of the work 
queues and pending queues, the disk controller can be 
automatically reinitialized when an error occurs. The 
disk driver monitors the time that each user request is 
on the pending queue in order to detect failures of the 
disk memory unit 
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METHOD FOR DISK I/O TRANSFER 

FIELD OF THE INVENTION 

This invention relates to a computer system having ^ 
one or more magnetic disk storage units abd, more 
particularly, to a method for efficient transfer of infor- 
mation between a central processing unit and the disk 
storage units. 

10 

BACKGROUND OF THE INVENTION 

Present day computer systems usuaUy include one or 
more magnetic disk units for bulk storage. In a multiuser 
system, each user has the capability to read records 
from and wtitc records to the disk units. Since disk 
operations take appreciable time in comparison with 
other computer operations, the efficiency with which 
disk operations are performed significantly affects over- 
all system performance. 

In general, the portion of a computer system associ- ^ 
ated with a disk unit includes the disk and associated 
drive hardware, disk controller software associated 
with the disk drive, disk driver software in the central 
processing unit and a communicadon channel between 
the disk driver and the disk controller. The disk driver 
receives requests from users via the operating system 
and communicates the requests through the communi- 
cation channel to the disk controller. The disk control- 
ler receives the requests from the disk driver, provides 
the necessary signals to the disk drive hardware and ^ 
returns information to the disk driver. 

A user disk read or write request may involve several 
operations on a machine level. In prior art systems, the 
disk controller received only one instruction, such as 
SELECT. SEEK. READ or WRITE, at a time. Until 35 
the previous command was executed, the controller did 
not receive the next command. This mode of operation 
is inefQcient because the CPU is required to perform 
several operations during which time other user disk 
requests are required to wait. In addition, the disk con- 40 
troUer is not necessarily operating in the most efficient 
manner since it must execute each command in the 
order specified by the disk driver. 

SUMMARY OF THE INVENTION 

According to the present invention, these and other 
objects and advantages are achieved in a method for 
executing user requests for work by a disk memory unit 
in a computer system including a central processing unit 
(CPU) having a main memory and a disk memory unit SO 
interconnected to the CPU. The method comprises the 
steps of; for each user request received, placing a queue 
block representative of the user request on a work 
queu^ constructing a command block for each queue 
block placed on the work queue; forwarding each com- 55 
mand block from the CPU to the disk memory unit for 
execution; after each command block has been for- 
warded to the disk memory unit for execution, transfer- 
ring the associated queue block from the work queue to 
a pending queue; executing the user requests repre- 60 
sented by each command block in an order determined 
by the disk memory unit; and removing each queue 
block from the pending queue after the disk memory 
unit hds completed the associated user request. The 
conmiand block forwarded to the disk memory unit 65 
contains all the information necessary for execution of a 
use request. The work queue and the pending queue 
maintain records of user requests received and user 



requests forwarded to the disk memory unit for execu- 
tion, while permitting control of disk memory opera- 
tions to be transferred to.the disk memory unit. 

Each queue block in the work queue and in the pend- 
ing queue and each command block has a unique identi- 
fication number which links it to a user request. As a 
result, user requests can be executed by the disk mem- 
ory imit in an order that is unknown to the CPU. 

A status block indicative of the status of a user re- 
quest is constructed by the disk memory unit and is 
forwarded to the CPU. The status block includes an 
interrupt type, the identification number received in the 
associated command, and status words which indicate 
errors and other information. The disk memory unit 
notifies the CPU via an interrupt and the status block 
when a command has been read. Each time the CPU is 
notified that a command block has been read, the work 
queue is checked for additional user requests. When 
additional user requests are found on the work queue, 
the CPU is notified to process the user requests and 
forward the required command blocks to the disk mem- 
ory unit. As a result, user requests are quickly for- 
warded to the disk memory unit and the CPU is made 
available for other work. 

The disk memory unit also requests the CPU via an 
interrupt and the status block to set up a data transfer 
channd when the disk memory unit is ready for transfer 
of data associated with a sp^ified user request to or 
from the disk memory unit. After a user request has 
been completed by the disk memory unit, the CPU is 
notified via an interrupt and the status block that the 
user request has been completed. 

According to another aspect of the invention, the 
time that each queue block has been on the pending 
queue is monitored and an error condition is generated 
when any of the queue blocks has been on the pending 
queue for longer than a mairimnm allowed time. The 
error condition causes the disk memory unit to be reini- 
tialized. The work queue and the pending queue each 
have an associated head and a tail. Preferably, the step 
of reinitializing the disk memory unit includes the step 
of appending the queue blocks in the pending queue to 
the head of the associated work queue and initializing 
the pending queue to zero. As a result, user requests 
previously forwarded to the disk memory unit that 
would otherwise have been lost when the disk memory 
unit was reinitialized, are executed in the order that 
they were received. Reinitializing the disk memory unit 
includes the steps of converting from an intelligent 
mode of operation to a degraded, or dumb, mode of 
operation, downloading an intelligent mode disk con- 
troller program from the CPU to the disk memory unit 
and resuming operation in the intelligent mode. E>own- 
loading of the disk controller program and resuming 
operation in the intelligent mode can occur automati- 
cally without the knowledge of or intervention by the 
user. 

The step of constructing a command block includes 
the step of writing command information to a specified 
location in main memory, and the step of forwarding 
each conmiand block from the CPU to the disk memory 
unit includes the step of notifying the disk memory unit 
to read command information from the specified loca- 
tion in main memory. The step of constructing a status 
block includes the step of writing status information to 
a specified location in main memory, and the step of 
forwarding the status block from the disk memory unit 
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to the CPU includes the step of notifying the CPU to 
via an interrupt read the status block from the specified 
location in main memory. 

The status block is forwarded to the CPU by means 
of a vectored interrupt. The interrupt sets a flag indicat- 5 
ing that the status block has been forwarded to a speci- 
fied location in memory and is available for access. The 
disk driver is able to identify spurious interrupts, to 
record an error and to continue operation. The disk 
memory unit has the capability of sensing specified 10 
internal and external events and error conditions unre- 
lated to any user request and forwarding them to the 
CPU via the status block. The specified events are 
logged by the CPU, or processed in a predetermined 
manner. Unrecoverable errors result in the disk mem- 15 
ory unit being automatically reinitialized as described 
above, and operation is resumed without intervention 
by the user. 

The disk driver includes a trace function that can be 
selectively enabled for tracking system operations and 20 
errors. When the trace function is enabled, a real time 
entry is made in a trace table for each command block, 
ea^h interrupt and each error that is handled by the disk 
driver.~The-trace^table^thus-cpntains a traffic record 
^useful for diagnostic purposes.* 25 
'-^According to another aspect of the invention, there is 
provided a method for executing user requests for work 
by a disk memory unit in a computer system including a 
central processing unit (CPU) haying a main memory 
and a disk memory unit interconnected to the CPU. The 30 
method comprises the steps of: for each user request, 
forwarding a command block that fully specifies the 
user request from the CPU to the disk memory unit, the 
conmiand block containing a unique identifier, resum- 
ing normal operation of the CPU until notified by the 35 
disk memory unit of the status of the specified user 
request; executing the user request specified by the 
command block at a time determined by the disk mem- 
ory unit; and notifying the CPU of the status of the 
^>ecified user request via an interrupt and a status block 40 
containing the unique identifier. For user requests re- 
quiring data transfer to or from the disk memory unit, 
the method further includes the steps of notifying the 
CPU via an interrupt and the status block containing the 
unique identifier to set up a data transfer channel when 45 
the disk memory unit is ready for transfer of data associ- 
ated with the specified user request, and transferrring 
data associated with the specified user request to or 
from the disk memory unit under control of the disk 
memory unit. 50 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a better understanding of the present invention 
together with other and further objects, advantages and 
capabilities thereof, reference is made to the accompa- 55 
nying drawings which are incorporated herein by refer- 
ence and in which: 

FIG. 1 is a block diagram of a computer system incor- 
porating the present invention; 

FIG. 2 is a block diagram illustrating the interrela- 60 
tionship of software elements in the system of the pres- 
ent invention; 

FIG. 3 illustrates the data structure of a command 
block in the system of the present invention; 

FIG. 4 illustrates the data structure of a status block 65 
in the system of the present invention; 

FIG. 5 illustrates he data structure of a DMA block in 
the system of the present invention; 



FIG. 5A illustrates the format of an INITIALIZE 
AND INTERRUPT command; 

FIG. 5B illustrates the format of a DOWNLINE 
LOAD command; 

FIG. 6 is a flow diagram illustrating the general oper- 
ation of the call routine in accordance with the present 
invention; 

FIG. 7 is a flow diagram illustrating the general oper- 
ation of the disk driver routine in accordance with the 
present invention; 

FIG. 8 is a block diagram illustrating the structure of 
the woric and pending queues in the disk driver, 

FIG. 9 is a flow diag^ram illustrating the routine for 
processing a phantom interrupt; 

FIG. 9A is a flow diagram illustrating the operation 
of the GET CONTROLLER STATUS routine; 

FIG. 10 is a flow diagram illustrating the routine for 
processing a spurious interrupt; 

FIGS. IIA and IIB are flow diagrams illustrating the 
routine for processing a COMMAND READ interrupt; 

FIG. 12 is a flow diagram illustrating the routine for 
processing a TRANSFER REQUEST interrupt; 

FIG. 13 is a flow diagram illustrating the routine for 
processing a BUFFER ACQUIRED interrupt; 

FIGS. 14A and 14B are a flow diagrams illustrating 
the routine for processing a COMPLETION interrupt; 

FIGS. 15A and 15B are flow diagrams illustrating tiie 
routine for processing an ERROR interrupt; 

FIG. 16 is a flow diagram illustrating the routine for 
processing an UNSOLICITED interrupt; 

FIG. 17 is a flow diagram illustrating the routine for 
processing a RETURN CONTROLLER INFORMA- 
TION interrupt; 

FIG. 18 is a flow diagram illustrating the routine for 
processing a user request; 

FIG. 19 is a flow diagram illustrating the routine for 
processing a clock interrupt; 

FIGS. 20A and 20B are flow diagrams illustrating the 
operation of the ABORT CONTROLLER routine; and 

no. 21 is a simplified block diagram of a portion of 
the disk controller program. 

DETAILED DESCRIPTION OF THE 
INVENTION 

A computer system incorporating the present inven- 
tion is shown in block diagram form in FIG. 1. A com- 
puter 10 includes a central processing unit (CPU) and a 
main memory. A plurality of user terminals 20a. 
20^20n may communicate with and utilize the com- 
puter 10. The COTiputer 10 is connected to one or more 
disk memory units. In the present example, the com- 
puter 10 is connected to four disk controllers 22, 24, 26, 
28. each of which handles four disk drives 30, 32, 34, 36. 
The mAnimum number of disk drives per controller 
depends on the design of the disk controller. The system 
is designed to handle up to eight disk controllers, each 
having eight disk drives. In the computer 10, an operat- 
ing system includes a disk driver program for each disk 
controller. Each disk controller ^ 24, 26, 28 includes a 
disk controUer program which communicates with the 
respective disk driver program in the CPU 10. 

The interrelationship of the disk driver program, the 
disk controller program for a single disk controller and 
user application programs is shown in FIG. 2. A plural- 
ity of application programs 40a, 40b~40n run in a time- 
shared manner on computer 10. When the application 
programs 40a 406-40/1 require work to be done by the 
disk memory units, user requests are forwarded to a disk 



11/12/04, EAST Version: 2.0.1.4 



4,888,691 



driver program 44 that is part of the operating system. 
The user requests are processed by a call routine 46 in 
the driver program 44. The call routine uses each re- 
quest as a set of arguments to construct a user disk 
request queue block that is placed on a work queue 48. 
A driver routine 50 is notified by the call routine via a 
disk semaphore 50a that a user request has been re- 
ceived. 

The driver routine 50 accesses user request queue 
blocks in the work queue 48 and constructs command 
blocks 52 that fully specify the user request. The com- 
mand blocks 52 are forwarded to a disk controller pro- 
gram 54 in the disk memory unit After the command 
block is forwarded to the disk controller program 54, 
the corresponding user request queue block is trans- 
ferred by the driver routine 50 from the work queue 48 
to a pending queue 56 until the user request is com- 
pleted. 

The disk controller program 54 communicates the 
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the controller successfully, the downline load is com- 
plete. 

The basic control sequence between the disk driver 
and the disk controller is through channel order packets 
of different types. The different channel order types are 
as follows: (1) initialize; (2) downline load; (3) com- 
mand; (4) status; (5) DMA. Each of the channel orders 
is explained in detail hereinafter. The link between the 
driver and the controller is a series of command blocks 
sent to the controller by the driver and a series of status 
blocks returned by the controller to the CPU through 
the driver. The status blocks contain interrupt codes 
which are used to sequence disk requests to completion. 

COMMUNICATION PROTOCOL 

The protocol for communication between the CPU 
and the disk controller is an asynchronous communica- 
tion protocol Commands and other parameters are 
passed by a non-interruptible, high speed data transfer 



status of the user request to the disk driver program 44 20 (DMT) and data is transferred by direct memory access 



via a status block 58. The status block 58 is forwarded to 
the driver routine 50 by an interrupt which notifies the 
disk semaphore 50a. The status block 58 is used to indi- 
cate that a command block 52 has been read and* subse- 
quently, the status block 58 is used to request setup of a 
DMA data transfer. The driver program 44 then for- 
wards a DMA block 60 specifying the DMA channel 
information to the disk controller program 54. The 
actual data transfer occurs via a DMA data path 62 



(DMA). The communication protocol is structured to 
allow the disk controller to obtain all the pertinent 
information about each command, such as READ or 
WRITE, at one time, and thereby allow the controller 
23 microprocessor to make intelligent decisions about how 
it will handle each command. The controller returns 
data to the CPU in record units only, except for status 
information. 

The interface protocol consists of a handshaking 



through a data window 64 in the CPU to a buffer in the 30 sequence between the CPU and the disk controller 



specified application program 40a, 406-40ff . After com- 
pletion of the data transfer, the disk controller program 
54 notifies the driver program 44 via the status block 58 
that the user request has been completed. A CPU clock 
66 interrupts the driver routine 50 via the disk sema- 
phore 50a at periodic intervals for timing each opera- 
tion and generating an error condition when a timeout 
occurs. The necessary data structures and operating 
routines are described in detail hereinafter. 

The purpose of the disk control subsystem of the 
present invention is to generally increase the overall 
throughput of disk I/O transfers. The efficiency of the 
disk subsystem is increased by the following features. 
(1) All pertinent information about each command is 
transmitted to the disk controller as soon as possible. 
This permits the disk controller to make intelligent 
decisions about how it will handle each and every com- 
mand. (2) The queuing algorithm that governs the disk 
seeking order is performed on the disk controller. (3) 
Retry operations in reading or writing are performed by 
the disk controller rather than the disk driver program 
associated with the CPU. (4) Error correction is per- 
formed to the extent possible by the disk controller. (5) 
The disk controller can accept multiple commands for 
the same disk driver, thereby freeing the disk driver 
software for other operations in a shorter time. (6) The 
channel program overhead is offioaded to the disk con- 
troller. 

The disk controller has the capability to receive and 



under which communication and data blocks are passed 
between the two. Data words known as OTA*s (output 
through register A) are used by the CPU to initiate an 
acdon by the controller, and interrupts are used by the 
35 controller to notify the CPU that an action has been 
completed. As noted above, the communication blocks 
used in the protocol fall into one of the following five 
categories: (1) initialize block; (2) downline load block; 
(3) command block; (4) status block; (5) DMA block. 
40 The initialize block and downline load block are used 
by the CPU in order to load the controller program into 
the disk controller and switch the controller from a non 
intelligent mode into the intelligent mode. The com- 
mand blocks are sent from the CPU to the controller 
43 and define a command to be executed by the controller. 
The status blocks are sent from the controller to the 
CPU and contain status information. The DMA blocks 
are sent from the CPU to the controUer and contain 
DMA channel and chain information to be used by the 
50 controller for DMA data transfer. All of these commu- 
nication blocks are transferred between the CPU and 
the controller using DMT transfers. 

OTA'S 

53 The disk driver notifies the disk controller of re- 
quired operations by using OTA 's, There are five 
OTA'S defined for this purpose. OTA 10, 11. 12, 13 and 
00. The controUer must be nonbusy to programmed 
input/output to accept an OTA. Since the controller 



queue multiple requests. The controller performs its 60 can go busy at any time, the CPU must attempt an OTA 



own SEEK optimization. Error correction b performed 
automatically after a prescribed number of unsuccessful 
attempts to read or write a record. 

In order to initialize the disk control subsystem the 
disk controller program must be downline loaded to the 65 
disk controller. The operating system m the CPU reads 
the controller program from the system disks and sends 
it to the controller. When the entire program is sent to 



and if the controller is busy, either constantly attempt 
the OTA or try again later. 

An OTA 10, 11, 12 or 13 is used to send the starting 
address of a command block. On receipt of an OTA, the 
controller fetches the command block from memory. 
The controller remains busy while fetching the com- 
mand block. After the command block is fetched, the 
controller sends a COMMAND READ interrupt ac- 
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